P1B: Refactor (packages/tui/src/util/format.ts:1): Function with many returns - #17

1. Issue

Link to the associated GitHub issue: #15

Full path to the refactored file: packages/tui/src/util/format.ts

What do you think this file does?
It exports formatDuration(), a pure utility used by the TUI to turn a raw second count into a short human-readable string (e.g. "5m 30s", "~2 days"), picking the right unit — seconds, minutes, hours, days, or weeks — based on the magnitude of the input.

What is the scope of your refactoring within that file?
The entire formatDuration() function (the file's only export, lines 1–20 originally, now 1–23).

Which Qlty-reported issue did you address?
Function with many returns at packages/tui/src/util/format.ts:1 — formatDuration had 6 separate return statements, one per branch.

2. Refactoring

How did the specific issue you chose impact the codebase's maintainability?
Six exit points meant the function's actual behavior was scattered across the body instead of having one clear place where the result gets produced. Anyone modifying a branch (e.g. changing the day/week threshold) had to trace through multiple independent returns rather than reason about a single control-flow path.

What changes did you make to resolve the issue?
I converted the sequential if (cond) return X statements into a single if / else if / ... / else chain that assigns to a local result variable per branch, with one return result at the end. The six conditions and the values computed in each branch are unchanged.

How do your changes improve maintainability? Did you consider alternatives?
There's now exactly one return, so the function has a single, unambiguous exit point — easier to add logging, wrap in a try/finally, or extend later without hunting down multiple returns. I considered rewriting it as a table-driven loop over {threshold, formatter} entries, which would also resolve the smell, but that's a bigger structural change for what's fundamentally a return-count issue, not a complexity issue — the if/else-if version is the smaller, lower-risk fix that doesn't introduce a new abstraction the file didn't already need.

3. Validation

How did you validate that the change is correct?
The refactor keeps the same 6 conditions and the same computed value in every branch, and all 7 existing tests in packages/tui/test/util/format.test.ts pass unchanged — including the explicit boundary-value test (59/60, 3599/3600, 86399/86400, 604799/604800). Coverage confirms the tests exercise the change directly: bun test --coverage reports 100% function and 100% line coverage on format.ts, with no uncovered lines. Qlty confirms the smell is gone: qlty smells --no-snippets packages/tui/src/util/format.ts returned no output (previously reported "Function with many returns (count = 6)" at line 1). bun lint reports no findings in format.ts.

Attach a screenshot of the test coverage showing the lines were executed by the tests.

Attach a screenshot showing the tests that cover the change passing during CI

Attach a screenshot of qlty smells --no-snippets <full/path/to/file.ts> showing fewer reported issues after the changes.

Screenshot of bun lint and bun test passing locally